Day1 NiFi 導讀與前言

2021 iThome 鐵人賽

DAY 1

AI & Data

Apache NiFi - 讓你輕鬆設計 Data Pipeline系列第 1 篇

13th鐵人賽 nifi nifi-registry data-pipeline

Mars Su

2021-09-16 10:37:47

13440 瀏覽

分享至

我是誰？這系列的目的是？

先來簡單自我介紹一下，我是 Mars。
目前在公司擔任 Data / ML Engineer，但除了接觸 Data 相關的任務之外，我本身也會去參與一些 ML 相關專案。所以對於 Data Pipeline 和 ML Pipeline 都有相關的經驗。

而這次系列分享的目的，主要是希望能從自身經驗中來分享一個在台灣比較少人提到跟討論的服務工具 - Apache NiFi，這是一個 Data Pipeline 的 opensource，但通常在台灣講到這個議題時，一開始可能都會想到像是 Apache Airflow, AWS Data Pipeline等服務工具，甚至自己額外程式撰寫去執行，比較少人去聯想到它。但其實這個服務在國外是成長地非常成熟，有許多很好的 UseCase，所以來透過這次的鐵人30天活動讓帶大家能認識到這個服務的性質與使用場景。

前情提要

在一開始就先來做簡單的導讀。如同簡介所說，在這次的系列文當中，我要介紹一個 Data Pipeline 的工具服務 - Apache NiFi。

首先，到底何謂 Data Pipeline 呢？我們依據下圖來簡單說明，可以想像有一個既有的 Source Data，我們從這裡面讀取數據，經過我們中間 Pipeline 的時候，Data 會經過一些邏輯的轉換或清洗，最後再落地到 Target Data 作存放或是交由其他服務做後續處理。

其中 Source Data 和 Target Data 通常為能存放資料的地方，較常見的有:

Local File (ex. csv, parquet, json, etc.)
RDB (ex. MySQL, MariaDB, PostgreSQL, etc.)
Document DB (ex. MongoDB, etc.)
NoSQL (ex. Cassandra, ScyllaDB, etc.)
Search Engine (ex. elasticsearch, etc.)
Data Storage (ex. AWS S3, GCP GCS, HDFS, etc.)
DataWarehouse (ex.AWS Redshift, GCP BigQuery, etc.)
Message Queue (ex.Apache Kafka, AWS Knesis, etc.)
SQL Engine (ex. Presto, AWS Athena, etc.)
API (ex. 透過請求 API 將資料轉移到下一個服務)

所以簡單來說，只要是能存放資料的地方，我們都可以從中取得資料，再經由 Pipeline 的轉換來做寫入以利於後續的任務做使用。

而 Pipeline 的轉換非常多樣，會依照使用場景跟需求不同而有所設計，最常見的有:

移除不必要的欄位
欄位值的格式轉換與解析
計算與加入統計分析相關數據等

接著，由於目前大環境的現況，在實際應用中我們會很常面臨到需要做大量資料轉換的場景，可能要整合多個 Datasource 然後做整併處理，來給商業端或是ML相關的下游做應用，所以 Data Pipeline 在真實場景上其實是扮演著一個非常重要的角色。

也正因為其之重要性，所以延伸出許多相關服務，像是常見的 GCP Data Fusion、GCP Dataflow、AWS Data Pipeline等，但這些常見的都是在各自的 Cloud，因此能對接的也都以自身 Cloud 的 Datasource 居多，例如 AWS 就只能接 AWS 自己的 DB 或 Storage，GCP 也是。那 Apache Airflow 呢？要說他是他其實在目前大多數的應用確實是，說不是也確實不是，因為 Airflow 在當初的發展理念主要是以 Workflow 為主，所以它並不是很純的 Data pipeline 工具，這部分會在後續有一篇來單獨介紹這中間的差異性。

Apache NiFi 特點簡介

而我們這次的主軸 Apache-NiFi，它擁有以下幾個重要特點：

支援 AWS, GCP, Azure 之 cloud db 和 storage 相關服務，ex. S3, GCS, PubSub, Knesis等。
支援 opensource DB，ex. Cassandra, MySQL, MongoDB等。
主要透過 Web UI 視覺化之設定與拖拉的方式即可建立 Data pipeline。
可以 Batch 和 Streaming 做切換。
具備 Monitoring 機制來監控 data 的處理狀況。
具備 Module Group 的機制，讓 Pipeline 變成模組來重複使用。
可建置成clustering(叢集)，來使大量資料做 load balance。
可針對 Data pipeline 去達到像 Git 一樣的版本控制，讓使用者可以指定版本去使用對應的 pipeline。
可搭配自己撰寫的 Script (ex. python, golang, etc.)去做資料處理與控制。
容易追蹤每筆資料的流向與轉換狀況。
對於錯誤處理有提供完善的措施。
如果 Pipeline 有問題時，不需要停止 Pipeline的運作，只要針對特定的 Processor 作處理即可。

那 Apache-NiFi有沒有缺點，其實也是有的，如下：

介面設定的參數較多，涵蓋的 Component 也較多，所以時常需要搭配 document 去做實作與理解。
需要 Self-hosted 和 Self-maintain。
假如是Clustering(叢集)的狀況下，若需要再額外加入一個 node，需要將服務 downtime，接著更改設定再重啟。
台灣本身的 Community 和 UseCase 相對較少，但在國外有許多 Community 和相關的資源與 Case 可以去做參考跟查找。

那基於以上特點與性質，我先在這裡大概提一下，可能有些人覺得聽起來不錯、有些人覺得還好，但對我來說這就是一個選擇，依照不同的使用場景選擇適用的工具這才是重要的，但至少在我的經驗中使用 Apache Nifi 是有一定的成效跟好處，所以也希望將此服務好好地介紹給各位。在接下來的30天會帶著大家一步一步地理解 Apache Nifi 的性質與特點是什麼意思，以及如何去實作操作它。